With the advent of Internet applications, computing system requirements and demands have increased dramatically. Many businesses, for example, have made important investments relating to Internet technology to support growing electronic businesses such as E-Commerce and other Internet related activities. Since companies are relying on an ever increasing amount of network activity to support their businesses, computing systems generally have become more complex in order to substantially ensure that servers providing network services continue serving the desired network load. Consequently, system reliability is an important aspect to the modern business model.
A first approach for providing powerful and reliable services may be associated with a large multiprocessor system (e.g., mainframe) for managing a server, for example. Since more than one processor may be involved within a large system, services may continue even if one of the plurality of processors fail. Unfortunately, these large systems may be extraordinarily expensive and may be available to only the largest of corporations. A second approach for providing services may involve employing a plurality of lesser expensive systems (e.g., off the shelf PC) individually configured as an array to support the desired load. Although these systems may provide a more economical hardware solution, system management and administration of individual servers may generally be more complex and time consuming than large dedicated systems.
Currently, management of a plurality of servers may be a time intensive and problematic endeavor. For example, managing server content (e.g., software, configuration, data files, components, etc.) generally requires administrators to explicitly distribute (e.g., manually and/or through custom script files) new or updated content and/or configurations (e.g., web server configuration, network settings, etc.) across the servers. If a server's content becomes corrupted, an administrator often has no automatic means of correcting the problem. Furthermore, configuration, load-balance adjusting/load balance tool selection, and system-wide monitoring generally must be achieved via separate applications. Additionally, if one or more servers become disabled (e.g., system crash/failure), administrators often have to manually bring a new server on-line to service the required load. Thus, management of the entity (e.g., plurality of computers acting collectively) as a whole generally requires individual configuration/administration of loosely coupled servers whereby errors and time expended are increased.
Presently, there is not a straightforward and efficient system and/or process for managing, administering, and scaling an application across a collection of independent servers. Many problems are thereby created since administrators may be generally required to work with machines individually to setup/deploy application content/tools and/or monitor/administer each server. Due to the need to administer and modify content on each machine individually, errors are a common occurrence. For example, it is routine for portions of server content to get out of sync with a master copy of the content associated with the collection of servers. Additionally, setting up load-balancing for servers, wherein each server may be given a suitable amount of work, is often a painful and error prone process. For example, load balancing often requires knowledge of intimate details of load-balancing tools which are often difficult and complex to work with.
Still yet another problem associated with management and administration is related to receiving system wide performance results and/or status of the collection of servers. Some applications may exist that provide performance and/or status of an individual server, however, these applications generally do not provide performance or status across the logical collection of loosely coupled servers. For example, many times it is important to view information from the collection of servers to determine relevant system-wide performance. Thus, getting a quick response view of pertinent performance information (e.g., requests/second, members used) associated with the plurality of servers may be problematic, however, since each server generally must be searched independently.
Currently, there is not an efficient and straightforward/consistent architecture for managing and administering an entity without substantial and sometimes complex individual configuration/monitoring of each member associated with the entity. Consequently, there is an unsolved need in the art for a systems architecture to manage, administer, configure and monitor a group of servers operating as an entity in order to scale the system to supply the desired load.